Remote monitoring and control of implantable devices

ABSTRACT

A treatment system includes a regulator implanted within a patient, a computing device storing at least one patient database associated with the patient in whom the regulator is implanted, and a data transfer device. The data transfer device provides bi-directional communication (e.g., voice communication) and a data exchange (e.g., a treatment history, a patient database, and operational instructions) between the regulator and the computing device. A programmer can obtain patient reports and/or default treatment values from the computing device based on the data exchange.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of application Ser. No. 13/292,530,filed Nov. 9, 2011, which is a continuation of application Ser. No.11/716,353, filed Mar. 9, 2007, now U.S. Pat. No. 8,068,918, issued Nov.29, 2011, which application is incorporated herein by reference in itsentirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention pertains to monitoring and controlling therapeutictreatment. More particularly, this invention pertains to remotelymonitoring and controlling therapeutic devices.

2. Description of the Prior Art

FIG. 1 illustrates a conventional therapeutic system 100 including animplantable device (i.e., a regulator) 110 and an external unit (i.e., aprogrammer) 130. The device 110 is typically implanted within a body ofa patient to provide treatment for a disorder. For example, inconventional cardiac rhythm management systems, the implanted device 110is an autonomous device connected to the heart of a patient to provideelectrical signals to regulate the heartbeat of the patient.Alternatively, the implanted device 110 can be connected to nerves ofthe patient to apply electrical signals to up-regulate or down-regulateneural activity on the nerves (e.g., the vagal nerves).

The implanted device 110 can record a treatment history of the patient.In such embodiments, the implanted device includes a memory 112 in whichthe treatment history (i.e., a record of events) can be stored. Examplesof typical events stored in a treatment history include delivery oftreatment to the patient, an attempt to transmit information to theexternal unit 130, and receipt of information from the external unit130.

In general, the external unit 130 is operated by a clinician (e.g., adoctor or other practitioner). The clinician can load treatment programs(i.e., instructions specifying the treatment regimen for the patient)onto the implanted device 110 using the external unit 130. The externalunit 130 also can download the stored treatment history from theimplanted device 110 and can transfer this history over a network 140 toa computing device 150, such as a server, for storage on memory 152.

Typically, the external unit 130 can communicate with the implanteddevice 110 when in proximity to the device 110. For example, theexternal unit 130 can connect to the implanted device 110 through aradio-frequency (RF) link. To change a patient's treatment schedule,update software on the implanted device 110, or obtain the storedtreatment history, therefore, a patient must visit the clinician'soffice or the clinician must travel to see the patient.

The conventional therapeutic system 100 shown in FIG. 1 also can includean optional controller unit 120. A patient can utilize the controllerunit 120 to manage the operation of the implanted device 110. Forexample, if the therapeutic system 100 is a pain management system, thena patient can use the controller unit 120 to increase or decrease thedosage or frequency of treatment. The controller unit 120 also canprovide power to the implanted device 110. For example, in anembodiment, the implanted device 110 provides treatment only when poweris received from the controller unit 120.

The controller unit 120 also can monitor the performance of theimplanted device 110 and can collect information from the implanteddevice 110. In such embodiments, the controller 120 can include a memory122 for storing the treatment history. The controller unit 120 isgenerally configured to communicate with the regulator 110 (e.g., via anRF signal). In such embodiments, the implanted device 110 may notinclude a memory. Rather, event indications can be transmitted to thecontroller unit 120 from the implanted device 110 as the events occur.

In some systems, the external unit 130 communicates with the controller120 instead of the implanted device 110. Typically, in such systems, theexternal unit 130 is placed in physical proximity to the controller 120to communicate with the controller 120. For example, the external unit130 can communicate with the controller unit 120 through a cableconnection (e.g., via a USB port) or an RF communication link. Here aswell, a patient visits the clinician's office or the clinician travelsto see the patient to transfer data between the clinician and thecontroller 120.

One conventional therapeutic system is described in U.S. Pat. No.6,564,102 to Boveja. The '102 patent discloses an implanted device foruse in neuromodulation therapy for coma and brain injury. The '102patent also discloses an external device that may have atelecommunications module to control predetermined programs remotely.Treatment parameter data can be viewed remotely by medical personnel viaa server on a personal computer or a Palm Pilot. U.S. Publication No.2005/0131467 to Boveja extends this concept to remote programming anddata exchange over a wide area network, and U.S. Publication No.2005/0131484 describes remotely interrogating and programming animplanted device over a wide area network.

SUMMARY OF THE INVENTION

This invention consists of therapeutic systems and methods for remotelymonitoring and/or controlling therapeutic devices.

The principal components of the system include a therapeutic device(i.e., a regulator) implanted within a patient and an external datatransfer device (DTD) for providing a communications link between theregulator and a remote device. For example, the external DTD can providedata transmission between the regulator and a remote computer, a remoteclinician programmer, or another remote device.

According to aspects of the invention, data synchronization can beprovided by compiling patient treatment information in patient databaseson a remote computing device and transferring the compiled informationpertaining to one or more patients to a requesting clinician programmer.

According to other aspects of the invention, patient reports can begenerated based on the compiled patient information and displayed toclinicians to aid in treatment analysis.

According to still other aspects of the invention, software updates forthe therapeutic devices in the therapeutic system can be providedautomatically from a remote computing device.

According to still other aspects of the invention, voice data and/orinformational data can be transferred between the clinician and thepatient, even when the clinician and patient are situated in remotelocations from one another.

In some embodiments, the external DTD also can operate the implantedregulator.

In other embodiments, the therapeutic system includes a separatecontroller unit enabling the patient to operate/manage the implantedregulator.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a conventional therapeutic system including animplantable device and an external unit;

FIG. 2 is a block diagram generally illustrating an exemplary treatmentsystem including a regulator, a controller, and a DTD configured inaccordance with the principles of the present invention;

FIG. 3 is a flowchart illustrating a communication process implementedby the DTD to transfer patient information from a controller to a remotecomputing device in accordance with the principles of the presentinvention;

FIG. 4 shows an operational flow of a complementary logic processfollowed by the remote computing device during the execution of portionsof the communication process of FIG. 3 in accordance with the principlesof the present invention;

FIG. 5 is a flowchart illustrating an operational flow for a generationprocess by which a patient report is generated in accordance with theprinciples of the present invention;

FIG. 6 is a flowchart illustrating an operational flow for a suggestionprocess by which the computing device or programmer can provide valuerecommendations for patient treatment in accordance with the principlesof the present invention;

FIG. 7 is an exemplary treatment summary display including aconfiguration section displaying treatment specification information, atherapy scheduler section displaying a therapy schedule, and an optionallive test screen in accordance with the principles of the presentinvention;

FIG. 8 is an exemplary treatment specification interface having multipletreatment attributes, such as amplitude of the treatment signal,frequency of the treatment signal, and lead configuration, to which aclinician can assign values in accordance with the principles of thepresent invention;

FIG. 9 is an exemplary therapy schedule interface divided into a summarysection and a management section in accordance with the principles ofthe present invention;

FIG. 10 illustrates an example embodiment of a patient use reportindicating whether the patient correctly used the treatment system overa period of time in accordance with the principles of the presentdisclosure;

FIG. 11 illustrates an exemplary graph mapping out correct usage of thetreatment system and issues experienced over one or more days ofscheduled therapy in accordance with the principles of the presentdisclosure;

FIG. 12 illustrates an exemplary daily patient usage report indicatingwhether the patient correctly used the treatment system over the courseof a given day in accordance with the principles of the presentdisclosure;

FIG. 13 is an exemplary therapy delivery report including a tableindicating for each day within a range of days whether treatment wasdelivered during a scheduled delivery time and, if not, why treatmentwas not delivered in accordance with the principles of the presentdisclosure;

FIG. 14 is a flowchart illustrating an operational flow of an updateprocess by which a remote computing device automatically updatessoftware on therapeutic devices of a therapeutic system in accordancewith the principles of the present disclosure;

FIG. 15A is a flowchart illustrating an assessment process by which aDTD can determine a current version of software operating on one or moretherapeutic devices of a therapeutic system in accordance with theprinciples of the present disclosure;

FIG. 15B is a flowchart illustrating an operational flow for an updateprocess by which a DTD checks for updates on a remote computing devicein accordance with the principles of the present disclosure;

FIG. 16 illustrates an example treatment system in which the DTD is acellular phone configured to transmit voice data and other data over anetwork in accordance with the principles of the present disclosure;

FIG. 17 illustrates an operational flow for an example communicationprocess for enabling a clinician to speak with the patient whiletransferring treatment information in accordance with the principles ofthe present disclosure; and

FIG. 18 is an example treatment system in which the controller and theDTD have been combined into a single manager device having a memory anda transmission unit.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following commonly assigned and copending U.S. patent applicationsare incorporated herein by reference: U.S. Publication No. 2008/0300656,A1, published Dec. 4, 2008; U.S. Publication No. 2005/0131485 A1,published Jun. 16, 2005; U.S. Publication No. 2005/0038484 A1, publishedFeb. 17, 2005; U.S. Publication No. 2004/0172088 A1, published Sep. 2,2004; U.S. Publication No. 2004/0167583 A1, published Aug. 26, 2004;U.S. Publication No. 2004/0172085 A1, published Sep. 2, 2004; U.S.Publication No. 2004/0176812 A1, published Sep. 9, 2004; and U.S.Publication No. 2004/0172086 A1, published Sep. 2, 2004.

With reference now to the various drawing figures in which identicalelements are numbered identically throughout, a description of thepreferred embodiment of the present invention will now be described. Inthe preferred embodiment, the invention is described with reference touse of a treatment system including a therapeutic device (i.e., aregulator) implanted within a patient and an external data transferdevice (DTD) for providing bi-directional communication between theregulator and remote devices. It will be appreciated the teachings ofthe present disclosure could be applied to any implantable apparatus fordispensing a therapeutic treatment to a patient.

For example, the invention can pertain to treatments of disordersassociated, at least in part, with neural activity. These may include,without limitation, gastrointestinal disorders (including obesity) andpancreo-biliary disorders. Alternatively, the invention can pertain totreatments of disorders associated, at least in part, with muscularactivity.

The present invention and its benefits can be better appreciated with adescription of preferred embodiments, which will now be described withreference to FIGS. 2-18. FIG. 2 is a block diagram generallyillustrating an exemplary treatment system 200 including a regulator210, a controller 220, and a data transfer device (DTD) 260 configuredin accordance with the principles of the present invention. Thetreatment system 200 also can include a programmer 230 and/or acomputing device 250 on which data (e.g., patient information, softwareupdates, etc.) can be stored, processed, and/or accessed.

In an embodiment, the controller 220 and the regulator 210 are generallythe same as the controller 120 and the regulator 110 of FIG. 1. In otherembodiments, the regulator 210 may not include a memory 212 in whichevents can be stored and time-stamped. In such embodiments, indicationsof events are transmitted from the regulator 210 to the controller 220or the DTD 260 for storage as they occur. Examples of treatment eventsto be stored can include, without limitation, treatment delivery events,patient use events, and battery charging events. Further detailsdescribing the types of events stored are provided herein.

The DTD 260 can be any type of data transfer device that is capable ofwirelessly communicating with the controller 220 (or the regulator 210)and transferring (e.g., downloading/uploading) electronic information toremote locations. In a preferred embodiment, the DTD 260 is a mobiledevice. Non-limiting examples of the DTD 260 include a personalcomputer, a notebook computer, a cellular phone, a personal digitalassistant (PDA), a smart phone, etc.

The DTD 260 can communicate with the controller 220 using a cableconnection (e.g., a USB cable, SCSI cable, coaxial cable, phone cable,etc.). In other embodiments, the DTD 260 can communicate with thecontroller 220 using a wireless connection. For example, the DTD 260 cancommunicate with the controller 220 over an RF signal or a CDMA signal.The controller 220 typically communicates with the regulator 210 via anRF signal. In an alternative embodiment, the DTD 260 communicatesdirectly with the regulator 210 using a wireless signal (e.g., an RFsignal).

The programmer 230 is generally the same as the programmer 130 disclosedin FIG. 1, except the programmer 230 is configured to communicate withthe DTD 260 remotely to obtain information from and transmit informationto the regulator 210. For example, the DTD 260 can communicate with theprogrammer 230 to receive treatment instructions and/or software updatesfrom the programmer memory 232. The DTD 260 also can transmit to theprogrammer 230 a treatment history identifying treatment events andindicating when each event took place. In an embodiment, the programmer230 is configured to communicate with the DTD 260 over a wirelessnetwork. In other embodiments, the programmer 230 is configured tocommunicate with the DTD 260 using any desired communication link.

The DTD 260 also can communicate with the computing device 250. In someembodiments, the computing device 250 can include a single computingdevice, such as a server computer. In other embodiments, the computingdevice 250 can include multiple computing devices configured tocommunicate with one another over a network (not shown). The computingdevice 250 can store multiple databases within memory 252. The databasesstored on the computing device 250 can be organized by clinic,practicing clinician, programmer identification code, or any otherdesired category.

In the example shown, the computing device 250 stores a first, second,and third database 254, 256, 258, respectively, in memory 252. Eachdatabase 254, 256, 258 can be associated with a particular patient. Eachpatient database 254, 256, 258 stores treatment history data, such asthe treatment events and patient use events (described in greater detailherein), obtained from the DTD 260 of the respective patient. As will berecognized by one of skill in the art, each database 254, 256, 258 canbe configured according to a relational model, a hierarchal model, anetwork model, or any other desired database model.

In an embodiment, the computing device 250 is configured to communicatewith the programmer 230 via the network 240. In another embodiment, thecomputing device 250 is configured to communicate with the programmer230 directly.

Data Synchronization

In general, the remote computing device 250 provides a global repositoryfor patient information. The computing device 250 can receive patientinformation from multiple programmers 230 and/or multiple DTD's 260. Aclinician can access the computing device 250 and obtain treatmentinformation for one or more patients using a programmer 230. In anembodiment, a single programmer 230 also can be shared among multipleclinicians (e.g., among clinicians working in the same office).

Each programmer 230 is configured to access the computing device 250 toobtain patient information from one or more patient databases whendesired by a clinician. All or part of the information contained in agiven patient database can be transferred to the programmer 230 uponrequest. The programmer 230 can store this information in memory 232 forlater use by the clinician. Storing the patient information on theprogrammer 230 enables the clinician to access the information at anytime, even when the programmer 230 is not communicatively linked to thecomputing device 250.

In some embodiments, each programmer 230 can determine whether theprogrammer 230 has all relevant patient information stored in its memory232. For example, the programmer 230 can determine treatment data ismissing (e.g., by comparing the date on which treatment was initiated,the current date, and the dates for which a treatment history isrecorded). If gaps exist in the treatment history stored on theprogrammer 230, then the programmer 230 can initiate communication withthe computing device 250 to request the relevant information.

Such a synchronization process enables the clinician to switchprogrammers 230 (e.g., if the original programmer 230 ceases tofunction) without losing patient data. Enabling data synchronizationbetween the computing device 250 and the programmers 230 also providesgreater freedom to patients in choosing treating clinicians. Forexample, if a patient wishes to obtain treatment from a differentclinician (e.g., due to job relocation, change in healthcare, desire tochange clinicians, etc.), then the patient can choose any cliniciancapable of accessing the computing device 250. The new clinician cancontinue patient treatment relatively uninterrupted by synchronizingpatient data between the clinician's programmer 230 and the computingdevice 250.

The chosen clinician can use the clinician's programmer 230 to obtainthe patient treatment history from the computing device 250. Armed withthe patient's treatment history, the chosen clinician can begin treatingthe patient without significant delay. Patients need not worry aboutcollecting the relevant documents from the original clinician or waitingfor the original clinician to find the time to transfer the informationto the new clinician.

Initiating Treatment

When using a therapeutic system configured in accordance with theprinciples of the present invention, the patient will not necessarilyneed to travel to the clinician's office, hospital, or other suchlocation to initiate a treatment regimen. The clinician can upload atreatment program to the patient's controller 220 from a remote locationthrough the DTD 260. For example, the clinician can transfer a treatmentprogram to the DTD 260 from the programmer 230 or from the computingdevice 250. Alternatively, if it is desired for the clinician to be inproximity to the patient during the initiation process, the controller220 can be connected to the programmer 230 through a cable or a wirelessconnection.

To initiate the treatment regimen, the clinician downloads a treatmentspecification and a therapy schedule to the patient's controller 220 ordirectly to the regulator 210. In general, the treatment specificationindicates configuration values for the regulator 210 and optionally forthe controller 220. For example, in the case of vagal nerve treatmentfor obesity, the treatment specification can define the amplitude,frequency, and pulse width for the electrical signals emitted by theimplanted regulator 210. In another embodiment, “ramp up” time (i.e.,the time period during which the electrical signals builds up to thedesired amplitude) and “ramp down” time (i.e., the time period duringwhich the signals decrease from the desired amplitude to about zero) canbe specified.

The therapy schedule indicates an episode start time and an episodeduration for at least one day of the week. An episode refers to theadministration of therapy over a discrete period of time. Preferably,the clinician programs an episode start time and duration for each dayof the week. In an embodiment, multiple episodes can be scheduled withina single day. Therapy also can be withheld for one or more days at thedetermination of the clinician.

During a therapy episode, the regulator 210 completes one or moretreatment cycles in which the regulator 210 sequences between an “on”state and an “off” state. For the purposes of this disclosure, atreatment cycle includes a time period during which the regulator 210continuously emits treatment (i.e., the “on” state) and a time periodduring which the regulator 210 does not emit treatment (i.e., the “off”state). Typically, each therapy episode includes multiple treatmentcycles. The clinician can program the duration of each treatment cycle.In an embodiment, the clinician can program the length of time overwhich the regulator is configured in the “on” state and the length oftime over which the regulator is configured in the “off” state. Whenconfigured in the “on” state, the regulator 210 continuously appliestreatment (e.g., emits an electrical signal). The regulator 210 iscycled to an “off” state, in which no signal is emitted by the regulator210, at intermittent periods to mitigate the chances of triggering acompensatory mechanism by the body. For example, if a continuous signalis applied to a patient's nerve for a sufficient duration, the patient'sbrain eventually can learn to develop an alternate nerve pathway totransmit the signal.

Follow-Up Treatment

Treatment history and other desired information stored by the controller220 or regulator 210 can be sent to the remote computing system 250 oranother data storage device. For example, FIG. 3 is a flowchartillustrating a communication process 300 implemented by the DTD 260 totransfer patient information from the controller 220 to the computingdevice 250 in accordance with the principles of the present invention.

The communication process 300 initializes and begins at a start module302 and proceeds to a first connect operation 304. The first connectoperation 304 communicatively couples the DTD 260 to the controller 220.For example, the first connect operation 304 can connect a transmissionunit 263 of the DTD 260 to a transmission unit 223 of the controller 220via a cabled connection, a wireless local area network (WLAN or Wi-Fi)connection, a wireless personal area network (WPAN) connection, e.g.,BLUETOOTH®, or any desired communication link.

A second connect operation 306 communicatively couples the DTD 260 tothe computing device 250. For example, the DTD 260 can communicate withthe computing device 250 over a network 240 (e.g., a wireless networkincluding a cellular network, a local area network (LAN), a wide areanetwork (WAN), etc.). In other embodiments, the second connect operation306 can couple the DTD 260 directly with the computing device 250.

A transfer operation 308 transmits treatment data (e.g., the identityand timing of treatment events) from the controller 220 or regulator 210to the computing device 250 via the DTD 260. In an embodiment, thetransfer operation 308 obtains the stored treatment events from thecontroller memory 222 (FIG. 2) and transmits the stored events to theDTD 260. The DTD 260 then transmits the obtained treatment data to thecomputing device 250. For example, the transfer operation 308 can obtainpatient use data, therapy delivery data, and/or battery charge data andsend this data to the computing device 250 for storage. In anembodiment, the transfer operation 308 encrypts the data beforetransmitting the data between the devices 220, 260, 250 in treatmentsystem 200. The communication process 300 can complete and end at a stopmodule 314.

In another embodiment, however, an optional obtain operation 310implemented by the DTD 260 receives or downloads from the computingdevice 250 a new set of therapy parameters and/or a new therapyschedule. A transmit operation 312 sends the obtained data to thecontroller 220 to upload to the regulator 210. The communication process300 completes and ends at the stop module 314. In alternativeembodiments, the DTD 260 implements communication process 300 directlywith the regulator 210 without using the controller 220 as anintermediary.

FIG. 4 shows an operational flow of a complementary logic process 400followed by the computing device 250 during the execution of portions ofthe communication process 300. The logic process 400 initializes andbegins at a start module 402 and proceeds to a receive operation 404.The receive operation 404 obtains from the DTD 260 data associated witha particular patient. In an embodiment, the receive operation 404obtains data indicating operation details of the therapeutic regulator210 over a period of time. In another embodiment, the receive operation404 obtains data indicating when therapy was delivered to the patient.

The receive operation 404 can be initiated by the DTD 260. For example,the DTD 260 can be configured to immediately upload the patientinformation to the computing device 250 after receiving the patientinformation from the controller 220 or from the regulator 210.Alternatively, the DTD 260 can be instructed by the programmer 230(i.e., the clinician) to upload the patient information to the computingdevice 250. In other embodiments, the computing device 250 can initiateimplementation of the receive operation 404. For example, the computingdevice 250 can periodically communicate with the DTD 260 to requestupdates of patient information.

A store operation 406 adds the newly obtained data to one or moredatabases stored on the computing device 250. For example, treatmentdata pertaining to a given patient can be stored in a databaseassociated with the given patient. If the computing device 250 does notinclude a database associated with the particular patient, then thestore operation 406 generates a new patient database in which to storethe information. As will be discussed herein, each patient database caninclude a log indicating when the therapeutic regulator 210 wasoperational, when treatment was delivered, and when and/or why treatmentfailed. In some embodiments, the logic process 400 completes and ends ata stop module 410.

In other embodiments, the logic process 400 proceeds to a synchronizeoperation 408, which sends the generated/updated patient database (e.g.,DB1 254) automatically from the computing device 250 to the programmer230 of the appropriate clinician. Alternatively, the synchronizationoperation 408 can provide the patient information to the programmer 230only upon receiving a synchronization request from the programmer 230.The logic process 400 completes and ends at a stop module 410 asdiscussed above.

In an example embodiment, the synchronize operation 408 described abovecan upload the patient database automatically to the programmer 230 viaa direct connection. In another embodiment, the synchronize operation408 can upload the patient database to the programmer 230 over a network240. In yet another embodiment, the synchronize operation 408 can sendthe patient database to the programmer 230 via email, a file transferprotocol (FTP) request, an HTTP request, or any other data transfermechanism.

The transferred patient information can be useful in a number ofapplications in addition to data synchronization, as will be describedin greater detail herein.

Patient Reports

Patient reports can be generated, e.g., by the programmer 230 or by thecomputing device 250, based on the compiled information stored on thecomputing device 250. In general, patient reports organize and formatcompiled treatment information and/or system usage information to aidthe clinician in determining the success of the treatment, identifyingissues hindering treatment, and/or counseling patients in effective useof the treatment system 200. Non-limiting examples of patient reportsinclude a therapy delivery report, a therapy history report, a patientuse report, a battery status report, and a lead status report.

FIG. 5 is a flowchart illustrating an operational flow for a generationprocess 500 by which patient reports can be generated. In an embodiment,the generation process 500 is implemented by the computing device 250.In another embodiment, the generation process 500 is implemented by theprogrammer 230. In other embodiments, the generation process 500 can beimplemented by any desired computing device configured to be accessed bythe clinician and/or the patient.

The generation process 500 initializes and begins at a start module 502and proceeds to an analyze operation 504. The analyze operation 504examines the information obtained from the patient database on thecomputing device 250 to identify treatment events. For example, theanalyze operation 504 can search the compiled information for atreatment event indicating the commencement of a therapy session and canidentify a timestamp indicating when the treatment event took place.

An evaluate operation 506 can compare the timestamp of the treatmentevent with the therapy schedule stored on the implementing computingdevice or stored on the regulator 210 to determine whether the treatmentevent occurred according to schedule. An organize operation 508 arrangesat least some of the identified treatment events and timestamps into ameaningful format to generate a patient report. For example, theorganize operation 508 can arrange selected treatment events inchronological order by date and/or time.

A display operation 510 renders the treatment event information fordisplay to the clinician, patient, or other user as one or more reports(e.g., a patient use report, a therapy delivery report, a batterycharging report, etc.). For example, the display operation 510 canselect particular treatment events (e.g., turning on the controller 220,aligning the controller 220 with the regulator 210, etc.) to display.Examples of patient reports are described in further detail herein. Thegeneration process 500 completes and ends at a stop module 512.

The generated patient reports can be analyzed by the clinician todetermine appropriate treatment modifications and/or to provideappropriate patient counseling on using the treatment system 200.

For example, a therapy delivery report can be used by the clinician toevaluate whether the treatment system 200 is functioning correctly. Ingeneral, the therapy delivery report indicates when therapy was providedto the patient by the regulator 210, when scheduled therapy was notprovided to the patient, and potential reasons the scheduled therapy wasnot provided. In an embodiment, the therapy delivery report displaysdates and times at which treatment events occurred. For example, thetherapy delivery report can display a date and time at which theregulator 210 began a therapy episode, a date and time at which theregulator 210 ended a therapy episode, and/or reasons therapy was notinitiated or discontinued prematurely. The therapy delivery report alsocan display events indicating user operational errors.

In an embodiment in which the patient controls the operation of theregulator 210, a patient typically is scheduled to operate the regulator210 (e.g., turn on and position the controller 220 adjacent theregulator 210) for a predetermined period of time each day. For example,a patient can be scheduled to operate the regulator 210 for a three hourperiod each day. Alternatively, the patient can be scheduled to rechargethe implant battery at a scheduled time each week. A patient use reportcan indicate to the clinician whether the regulator 210 was operated bythe patient each day at the scheduled time or whether the regulatorbattery was recharged according to schedule. The patient use report alsocan indicate potential sources of patient error in which the treatmentsystem 200 was used incorrectly or not at all.

A clinician can employ the patient use reports to aid in determining thesuccess of the treatment system 200 and the prescribed treatmentregimen. If the desired results are not achieved after using the system200 for a period of time, then the clinician may determine initially thesystem 200 is malfunctioning or the prescribed treatment regimen isineffectual. In response, the clinician may increase the frequency oftherapy episodes, increase the duration of each episode, and/or increasethe strength of the treatment to improve performance.

However, if the desired results were not obtained because the patientfailed to use the system 200 as directed (e.g., the patient did notposition the controller 220 properly with respect to the regulator 210,did not charge the controller battery, or did not turn on the controller220), then time can be lost in modifying the treatment regimenneedlessly. Furthermore, modifying the parameters of the treatmentregimen to increase frequency, duration, and/or strength of thetreatment based on inaccurate information can be dangerous to thepatient.

The patient use reports enable the clinician to distinguish moreaccurately between ineffective treatment parameters and system misuse bythe patient, thereby enabling the clinician to respond moreappropriately to treatment concerns. If the desired results were notachieved and the patient reports indicate the treatment system 200 wasused correctly and according to schedule, then the clinician may electto modify the treatment specification and/or the therapy schedule.

Alternatively, if the desired results were not achieved and the patientuse report indicates patient misuse, e.g., the patient repeatedly failedto turn on the controller 220, then the clinician may elect not tochange the treatment parameters. Instead, the clinician can work withthe patient to determine why the patient did not operate the system 200correctly and how to promote correct usage going forward. In otherembodiments, the clinician may elect to change the treatment parametersto better suit the patient's lifestyle (e.g., rescheduling therapyepisodes to occur at more convenient times).

A battery charge report also can be helpful in aiding the clinician tomonitor patient behavior with respect to the treatment system 200. Anexemplary battery charge report indicates dates and times during whichthe controller battery was recharged, charging, or not charged. Based onthis information, the clinician can counsel the patient on better habitsif the patient has been negligent about charging the controller batteryor recharging the regulator battery. Alternatively, the clinician canwork with the patient to adjust the therapy schedule to fit better withthe patient's lifestyle.

Providing Relevant Default Values

The patient information compiled on the computing device 250 can beprocessed by the treatment system 200 to provide relevant defaulttreatment parameters to a clinician. For example, the computing device250 can provide relevant default treatment specification values (e.g.,amplitude or frequency of the regulator signal) and/or therapy scheduledefault values (e.g., duration of therapy episodes, timing of treatmentcycles, etc.) to a programmer 230. Alternatively, the computing device250 can provide the programmer 230 with sufficient patient informationto enable the programmer 230 to determine relevant default values for aparticular patient.

Providing relevant default values can aid the clinician in selectingactual treatment values. The clinician can utilize the default values asa starting point in establishing appropriate treatment settings andtherapy schedules for the patient. Non-limiting examples of the types ofdefault values that can be provided by the treatment system 200 includethe type of treatment applied, the duration of each treatment, and theintensity of each treatment.

For example, in the case in which a regulator 210 is electricallycoupled to the vagal nerves of a patient to treat obesity, the cliniciantypically programs the frequency of the signal applied to the nerves,the duration of each signal, and how often the signal is repeated. Inthe case in which a regulator 210 is electrically coupled to thepatient's heart to aid in cardiac rhythm management, the clinician canspecify at what point the regulator 210 will apply treatment, theinitial dose applied, and the degree to which the dose is increased overtime.

Typically, the default values are generated to be relevant to aparticular patient. In some embodiments, the default values can beselected based on the track history of the patient. In otherembodiments, the default values can be selected based on settingsutilized with other patients having similar disorders or biologicalconfigurations. For example, the default values can be provided based ona determined success rate correlated to the parameter values used insimilar patients.

FIG. 6 is a flowchart illustrating an operational flow for an exemplarysuggestion process 600 by which the computing device 250 or theprogrammer 230 can provide relevant default values of patient treatmentparameters to the treating clinician. The suggestion process 600initializes and begins at a start module 602 and proceeds to a searchoperation 604. The search operation 604 queries the patient databasesstored on the computing device 250 for treatment specification and/ortherapy delivery values utilized with other patients having a biologicalmakeup, disorder, or other characteristic similar to the clinician'spatient.

An evaluate operation 606 compiles the search results and comparescorresponding treatment success rates. A select operation 608 determineswhich treatment specification and therapy delivery values tend tocorrelate with greater success rates in patients similar to theclinician's patient. A display operation 610 presents the selectedvalues to the clinician. For example, the display operation 610 canpresent treatment specification values to the clinician when theclinician is preparing an initial or modified treatment specificationfor the patient as discussed in greater detail herein. The suggestionprocess 600 completes and ends at a stop module 612.

In an embodiment, the programmer 230 can display the default values in atext box of a treatment specification programming interface. In anotherembodiment, the programmer 230 displays the default values in adrop-down menu or other interface tool used by the clinician to inputtreatment specification values. In an embodiment, a single default valueis displayed to the clinician per parameter. In another embodiment, arange of default values can be provided for a given parameter.

Example Application

Referring to FIGS. 7-13, the present invention can be best understood bywalking through an example application in which a clinician initiates atreatment program for a patient and then provides follow-up care for thepatient. For the purposes of this example application, the clinicianuses a programmer 230 to transfer a treatment specification and atherapy schedule to the DTD 260 for download to the patient's controller220. The DTD 260 also is utilized to transfer stored treatment eventsfrom the controller 220 to the computing device 250. In otherembodiments, the DTD 260 transfers data between the programmer 230, thecomputing device 250, and the regulator 210.

To initiate or modify patient therapy, the clinician views a treatmentsummary display on the programmer 230 or the computing device 250. Theclinician modifies the treatment specification data and/or the therapyschedule data presented to the clinician via the programmer 230. Forexample, the clinician can view and modify the treatment regimen via thetreatment summary display 700 as shown in FIG. 7. The modified data istransmitted from the programmer 230 to the patient's controller 220.

In the example shown, the treatment summary display 700 includes aconfiguration section 710 displaying treatment specificationinformation, a therapy scheduler section 720 displaying a therapyschedule, and an optional live test screen 730. The clinician canpopulate the treatment specification 710 by inputting values for one ormore treatment attributes. Default values relevant to a particularpatient can be provided in the configuration section 710 and the therapyscheduler section 720 as described above. In such embodiments, theclinician can populate the treatment parameter values based, in part, onthe default values.

An example of a treatment specification interface tool is shown at 800in FIG. 8. The treatment specification includes values 804 associatedwith treatment attributes 802. In the example shown, treatmentattributes 802 include amplitude of the treatment signal, frequency ofthe treatment signal, and lead configuration (i.e., anterior toposterior or vice versa). The clinician can modify the treatment values804 by typing information into the text boxes in which the values 804appear. Alternatively, the clinician can modify the treatment values 804by selecting from a list of possible values obtained via a menu tool806.

The therapy schedule also can be modified by the clinician on theprogrammer 230. An example of a therapy schedule display is shown at 900in FIG. 9. The therapy schedule 900 shown in FIG. 9 is divided into asummary section 910 and a management section 920. The summary section910 is broken out by day (e.g., in rows 912) and by hour (e.g., incolumns 914) to indicate at which times of day the therapy episodesshould be implemented.

In an embodiment, a therapy episode can be scheduled to begin at aspecific time each day. For example, the presence of a solid bar 916A inthe treatment summary section 910 indicates a therapy episode shouldbegin at 6:45 am and proceed until 9:15 am on Monday. In otherembodiments, therapy episodes can be scheduled to span two or more days(e.g., from late evening one day to early morning the next day).

Alternatively, multiple therapy episodes can be scheduled per day. Forexample, the solid bar 916B in the treatment summary section 910indicates a first therapy episode should begin at 11:30 am on Saturdayand end at 3:00 pm on Saturday. A second therapy episode (see 916C) isscheduled to begin fifteen minutes later at 3:15 pm on Saturday and toend at 4:45 pm on Saturday.

The treatment summary section 910 can be modified by the clinician toalter the therapy schedule of the patient. In some embodiments, theclinician directly interacts with the graphics displayed in the summarysection 910. For example, the clinician can move or stretch existingepisode time blocks to extend over different time periods via a mouse orother input tool. In the example shown, the clinician can choose whichtherapy episode to modify by selecting the corresponding indicia 916 inthe summary section 910.

In other embodiments, the clinician can use the treatment managementsection 920 of the display 900 to modify the therapy schedule. Ingeneral, the treatment management section 920 includes user interfacetools 922 (e.g., buttons, text boxes, check boxes, radio buttons, etc.)with which the clinician can modify the treatment schedule.

For example, in the embodiment shown in FIG. 9, the management section920 includes a first set of buttons to increment or decrement the starttime of a therapy episode and a second set of buttons to increment ordecrement the end time of a therapy episode. In other embodiments, themanagement section 920 can include additional user interface tools toadd, delete, and/or select therapy episodes, to adjust the timing oftreatment cycles, and to copy/paste therapy episodes between days.

In an embodiment, the start time and end time of each therapy episodecan be incremented or decremented in 15-minute units. In otherembodiments, episode time blocks can be defined in shorter or longerincrements. In an embodiment, the duration of the “on” time and “off”time of a treatment cycle can be specified in discrete time periods. Forexample, the duration of each state can be specified in one-minuteincrements. When the clinician has finished programming the therapyschedule, the settings can be saved by clicking on button 902 or anotherinterface tool. Alternatively, the clinician can restore or load adefault therapy schedule via interface tool 904.

The clinician can test the new therapy parameters using a live testoption 730 from FIG. 7. The live test feature 730 instructs theregulator 210 to begin a treatment episode immediately for a duration oftime. In an embodiment, the duration of the test episode ispredetermined by the clinician. In another embodiment, the treatmentepisode lasts until the clinician sends instructions to stop the episodefrom the programmer 230 via the DTD 260. Results of the test can bedisplayed to the clinician substantially in real-time on the programmer230 via the DTD 260. The clinician can modify the treatmentspecification and/or the therapy schedule based on the clinician'sanalysis of the displayed test results.

In general, the test results are transmitted from the regulator 210 tothe DTD 260 and then to the programmer 230. In an embodiment, the DTD260 accesses (i.e., establishes a communicative link with) theprogrammer 230 to transmit the test results to the clinician. In anotherembodiment, the programmer 230 accesses the DTD 260 to obtain the testresults. In yet another embodiment, the DTD 260 logs the test results onthe computing device 250. In such embodiments, the clinician candirectly access the computing device 250, access the computing device250 over a network, or access the computing device 250 via theprogrammer 230 to obtain the test results.

As discussed above, the clinician can monitor the effects of thetreatment regimen on the patient using the therapeutic system 200. Forexample, the computing device 250 and the DTD 260 can be configured totransfer and store treatment events from the regulator 210 periodically.The clinician can select any convenient time to follow up with thepatient or check-in on the patient's progress via the stored treatmentevents. To aid the clinician in the follow-up analysis, the computingdevice 250 or the programmer 230 can generate patient reports.

For example, FIG. 10 illustrates an exemplary patient use report 1000indicating whether the patient correctly used the treatment system 200over a period of time in accordance with the principles of the presentdisclosure. In the example shown, the report 1000 includes a table 1020listing patient usage statistics over a period of time. The range intime over which patient usage is displayed can be selected usinginterface tools (e.g., drop down menus, text boxes, etc.). In theexample shown, start and end dates for a date range can be selected fromdrop down menus 1002, 1004, respectively.

The patient use table 1020 has a first column 1021 listing dates withinthe specified range and a second column 1022 listing a percentage valueindicating a degree to which the patient utilized the system on therespective date. The table 1020 also includes columns identifyingpotential reasons the system was not used. In the example shown, thepatient use table 1020 includes five additional columns 1023, 1024,1025, 1026, 1027, each additional column identifying one potential causeof patient non-use.

The first two additional columns 1023 and 1024 identify problems with atransmission unit 223 (FIG. 2) of the controller 220. The first column1023 contains values indicating what percentage of the scheduledoperation time consisted of non-use due to the transmission unit 223 ofthe controller 230 being disconnected from (or out of contact with) thecontroller 220. The second of these columns 1024 indicates for each dayat what percentage of the scheduled operation time the transmission unit223 was incorrectly positioned with respect to the implanted regulator210. For example, according to the patient use table 1020 of FIG. 10,the transmission unit 223 was not properly connected just over 3% of thetime on Jan. 21, 2007 and only 0.01% of the time two days prior.

The second two columns 1025 and 1026 identify problems with the patientremembering to charge the battery of the controller 220. Column 1025contains values indicating what percentage of the scheduled operationtime consisted of non-use due to the controller 220 not being powered(e.g., not being charged). Column 1026 contains values indicating howoften the patient did not use the system because the system was chargingat the specified use time. In other embodiments, a column may indicateproblems in recharging the regulator battery. The final column 1027indicates how often the patient failed to use the system for unknownreasons.

As shown in FIG. 11, the patient use report can include a graph 1100mapping out correct system usage and problems experienced over one ormore days. In the example shown, a row 1110 of the graph 1100 representspatient usage for a particular day 1105. Each row 1110 extends from a 0%line to a 100% line. The row is broken into segments to indicate whatpercentage of each day corresponds with a particular operational status.A key 1115 identifying the segments is provided.

In the example shown, a first segment 1112 shown under Jan. 19, 2007indicates the system was used correctly for about 45% of the scheduledoperating time of Jan. 19, 2007. A second segment 1114 indicates thecontroller battery was charging for about 55% of the scheduled operatingtime. Other segments shown indicate the amount of time over which thetransmission unit 223 of the controller 220 was not properly connectedto the controller 220 or the system 200 was not operating correctly forunknown reasons on a given day.

If desired, a report can be generated for each day within a range ofselected dates. FIG. 12 illustrates an example of one such report 1200.In an embodiment, the daily patient usage report 1200 is chosen fordisplay by selecting a row displayed in the patient usage table 1020 ofFIG. 10 or a row 1110 in the graph 1100. The report 1200 includes atable 1220 having the same columns as table 1020 of FIG. 10. However,the values in the table indicate how often the patient correctlyoperated the system throughout a given day. In the example shown, thetable 1220 is divided into hourly segments 1221. Allowing the clinicianto analyze patient behavior in detail over the course of a day enablesthe clinician to design more effective therapy schedules to suit thelifestyle of a particular patient.

To determine whether treatment was delivered to a patient as scheduled,the clinician analyzes compiled information including treatment eventsrecorded by the controller 220 (or the regulator 210). The compiledinformation can be displayed in a therapy delivery report. An example ofa therapy delivery report is shown at 1300 in FIG. 13. The therapydelivery report 1300 includes a table 1301 indicating for each daywithin a range of days whether treatment was delivered during ascheduled delivery time and, if not, why treatment was not delivered.

In the example shown, the first column 1305 in table 1301 lists days onwhich treatment was scheduled. The second column 1310 indicates for eachday in column 1305 what percentage of the scheduled treatment wasdelivered to the patient in accordance with the therapy schedule. Forexample, if therapy was delivered to the patient for about half of thescheduled treatment duration, then the second column 1310 would containan indication of 50%.

The remaining columns (indicated generally at 1350) in the table 1301indicate potential reasons therapy was not delivered to the patient atthe designated times. One subset of possible reasons includes patienterror (e.g. forgetting to turn on the system). In the example shown, thecolumns (indicated generally at 1320) indicating patient error are thesame as some of the columns 1023-1026 found in the patient use report1000 of FIG. 10. In other embodiments, the columns 1320 can indicate theoccurrence of other patient errors or other reasons for patient non-use.

Additional potential causes of non-deliverance of treatment are listedin columns 1330, 1332, 1334, 1336, and 1338 of therapy delivery table1301. Column 1330 indicates when the transmission unit 223 of thecontroller 220 suffers from an electrical short. Column 1332 indicateswhen the wrong transmission unit 223 is coupled to the controller 220.Depending on circumstances, this problem source also could fall withinpatient error. Link errors and system errors are indicated in columns1336 and 1338, respectively. These errors may indicate a problem withthe operation of one or more of the devices 210, 220, 260 of the system200, rather than with patient usage.

Column 1334 indicates when the impedance of the regulator 210 (i.e., thestrength of the electrical signal transmitted between the regulator 210and the body of the patient) has decreased beyond a predeterminedthreshold. For example, the regulator 210 can be configured to transmitan electrical signal to first and second leads which are coupled tonerves or muscles of the patient. If one or both of the leads becomedetached from the nerves, or if a dielectric material builds up betweenthe leads and the nerves, then the impedance of the electrical signalwill decrease. If the impedance sufficiently decreases, then thedesignated amount of therapy will not be delivered to the patient.

Using the above described patient reports, the clinician can gain aclearer understanding of the effectiveness of the treatment system 200.In other embodiments, other types of patient reports can be utilized bythe clinician. For example, the clinician can view a battery rechargereport (indicating when the controller battery was recharged), a leadstatus report (indicating the impedance of the electrical signals of theleads), or a therapy history report (indicating prior treatmentspecifications and/or therapy schedules used with the patient).

Automatic Updating

Referring to FIGS. 14 and 15, the DTD 260 also can be used to providesoftware updates to the patient's controller 220 and regulator 210. FIG.14 is a flowchart illustrating an operational flow of a first exemplaryupdate process 1400 by which the computing device 250 initiates atherapeutic software update for one or more patients. Update process1400 automatically distributes the updated software to the patientdevices for installation.

In an embodiment, the computing device 250 updates the softwareexecuting on the regulator 210 of each patient. In another embodiment,the computing device 250 updates the software executing on thecontroller 220 of each patient. In yet another embodiment, the computingdevice 250 receives software updates for both the regulator 210 and thecontroller 220 of each patient. In other embodiments, the computingdevice 250 can receive software updates for any device in therapeuticsystem 200.

The first update process 1400 initializes and begins at a start module1402 and proceeds to a first receive operation 1404. The first receiveoperation 1404 obtains updated software for installation on one or morepatient devices 210, 220, 260 of a therapeutic system 200. For example,the first receive operation 1404 can acquire updated software from asoftware provider when a newer version is released. Alternatively,updated software can be downloaded to the computing device 250 by theclinician.

A second receive operation 1406 receives instructions from a clinicianto update the software on one or more devices 210, 220, 260 oftherapeutic system 200 with the software obtained in the first receiveoperation 1404. The instructions can specify a schedule according towhich the updates are to be downloaded and/or installed on thetherapeutic devices 210, 220, 260. A connect operation 1408 provides acommunications link between the computing device 250 and the DTD 260 ofeach patient scheduled to receive the updated software. Alternatively,the computing device 250 can be programmed to automatically initiatecommunication with the DTD 260 when relevant updated software isreceived.

A first transmit operation 1410 provides instructions from the computingdevice 250 to the DTD 260 to determine what software is installed on thedevices 210, 220 of the therapeutic system 200. For example, the firsttransmit operation 1410 can provide instructions to the DTD 260 toconnect to the controller 220 and query the controller 220 regarding theversion of the software executing on the controller 220 or the regulator210. In another embodiment, the first transmit operation 1410 canprovide instructions to the DTD 260 to communicate with the regulator210 to determine which version of software is installed on the regulator210.

A third receive operation 1412 obtains a response from the DTD 260regarding what software versions are installed on the devices 210, 220of the therapeutic system 200. An evaluate operation 1414 compares thesoftware version indicated in the response from the DTD 260 with thesoftware updates stored on the computing device 250. If the evaluateoperation 1414 determine the devices 210, 220 of the therapeutic system200 have the updated software already installed, then the update process1400 completes and ends at a stop module 1420.

Alternatively, if the evaluate operation 1414 determines that one ormore of the devices 210, 220 should be updated, then the update process1400 proceeds to a transmit operation 1416, which transfers the softwareupdates to the DTD 260 along with instructions to forward the updates tothe appropriate therapeutic devices 210, 220 of the therapeutic system200. An optional confirm operation 1418 can provide confirmation to thecomputing device 250 from the DTD 260 that the software updates weretransmitted to and installed on the appropriate therapeutic devices 210,220. The first update process 1400 completes and ends at stop module1420.

In an alternative embodiment, each individual DTD 260 can initiate adetermination of whether updated software is available for the devices210, 220 of the therapeutic system 200. For example, FIG. 15A is aflowchart illustrating an exemplary assessment process 1500A by whichthe DTD 260 determines the current version of software executing on thetherapeutic devices 210, 220 of system 200.

The assessment process 1500A initializes and begins at a start module1502 and proceeds to a connect operation 1504. The connect operation1504 provides a communication link between the DTD 260 and the patient'scontroller 220. As discussed above, the DTD 260 can communicate with thecontroller 220 via a cable connection or a wireless connection.Alternatively, the connect operation 1504 can provide a communicationslink between the DTD 260 and the regulator 210.

A query operation 1506 determines the current software versions storedand operating on the controller 220. In an embodiment, the queryoperation 1506 can determine the current software version operating onthe regulator 210. In one such embodiment, the query operation 1506queries the controller 220, which queries or has queried the regulator210. In another such embodiment of the query operation 1506, the DTD 260queries the regulator 210 directly.

A receive operation 1508 obtains a response indicating the softwareversion executing on the controller 220 and/or the software executing onthe regulator 210. The assessment process 1500A completes and ends at astop module 1510. In alternative embodiments, the DTD 260 can determinethe software version executing on itself.

FIG. 15B is a flowchart illustrating an update process 1500B by whichthe DTD 260, the controller 220, and/or the regulator 210 can obtainsoftware updates from an update source, such as the computing device250. Typically, the update process 1500B is executed by the DTD 260after execution of the assessment process 1500A discussed above. Theupdate process 1500B initializes and begins at a start module 1512 andproceeds to a connect operation 1514.

The connect operation 1514 provides a communication link between the DTD260 and a source of software updates. For example, the DTD 260 cancommunicatively link to the computing device 250, the programmer 230, oranother source of software updates. The communication link can beprovided over a communications network as described above.

A query operation 1516 searches the software update source, e.g.,computing device 250, for recent software updates. The query operation1516 can search for software configured to operate the DTD 260, softwareconfigured to operate the controller 220, and/or software configured tooperate the regulator 210. For example, the query operation 1516 canobtain a timestamp indicating the date and time at which the softwareupdate was uploaded/stored.

An evaluate operation 1518 compares the software stored on the updatesource with the software operating on at least one of the DTD 260, thecontroller 220, and the regulator 210. For example, the evaluateoperation 1518 can compare the timestamp associated with the softwarestored on the update source with a timestamp indicating when thesoftware was installed on a particular device 210, 220, 260.

If the evaluate operation 1518 determines the devices 260, 220, 210 ofthe system 200 are operating the most recent version of the relevantsoftware, then the update process 1500B completes and ends at a stopmodule 1524. Alternatively, if the evaluate operation 1518 determinessoftware updates exist for one or more of the devices 260, 220, 210,then the update process 1500B proceeds to an acquire operation 1520.

The acquire operation 1520 transfers the updated software from thesoftware source, e.g., computing system 250, to the DTD 260. The DTD 260can determine whether the updated software should be installed on theDTD 260 or whether the updated software should be distributed to thecontroller 220 and/or regulator 210 in a transfer operation 1522. Theupdate process 1500B proceeds to the stop module 1524 as describedabove. In an embodiment, the DTD 260 automatically implements theassessment process 1500A and the update process 1500B. In otherembodiments, however, the DTD 260 implements these processes 1500A,1500B at the prompting of the patient or the clinician.

In other embodiments, software operating on the programmer 230 can beupdated using a similar process. For example, the computing device 250can connect, either directly or through a network 240, to one or moreprogrammers 230. The computing device 250 can initiate a transfer ofupdated software to the programmers 230. Alternatively, each programmer230 can connect to the computing device 250 or other update source toassess whether software updates are available and download the updatesas appropriate.

Other Applications

Referring now to FIGS. 16 and 17, the DTD 260 is configured tofacilitate communication between the clinician and the patient duringremote programming and/or testing. For example, the DTD 260 can be acellular phone 260′ or other mobile device configured to transmit dataover a cellular network 240′ (e.g., a code division multiple access(CDMA) network, a frequency division multiple access (FDMA) network, oranother such network). Such a system 1600 is shown in FIG. 16.

The mobile device 260′ enables a clinician (e.g., via the programmer230, the computing device 250, or another remote computing device) tocommunicate (e.g., upload program information, provide testinginstructions, download treatment information, etc.) with a patient'scontroller 220, even if the patient is located at a remote distance fromthe clinician. The mobile device 260′ also enables the patient tocontact the clinician (or vice versa) at substantially any time,regardless of the patient's location (within the limitations of thenetwork 240′). The patient need not be located near a modem orhigh-frequency wireless local area network (Wi-Fi) connection.

In some embodiments, the mobile device 260′ also enables the clinicianto transmit and receive voice data to and from the patient. For example,the clinician can transmit oral instructions to the patient via thecellular phone 260′ as the clinician is adjusting the patient'streatment or conducting a live test (discussed in greater detail above).The patient can provide immediate feedback to the clinician regardingthe patient's physical and mental state as the regulator 210 is beingprogrammed or tested. In other embodiments, the mobile device 260′transmits textual, graphical, and/or executable data between theclinician and the patient.

FIG. 17 illustrates an operational flow for an example communicationprocess 1700 implemented by the cellular phone 260′ to enable theclinician to speak with the patient while transferring information toand/or from the controller 220. The example communication process 1700initializes and begins at a start module 1702 and proceeds to a connectoperation 1704. The first connect operation 1704 establishes acommunications link between the mobile device 260′ and the clinician.

For example, the connect operation 1704 can establish a communicationslink between the mobile device 260′ and the programmer 230 of theclinician. In another embodiment, the connect operation 1704 canestablish a communicative link between the mobile device 260′ and aremote computing device (e.g., a computing device networked to computingdevice 250) accessed by the clinician. In other embodiments, theclinician can connect to mobile device 260′ via a cellular phone orother mobile device of the clinician. For ease in understanding, thefollowing discussion will assume the clinician communicates with themobile device 260′ via the programmer 230.

A data transfer operation 1706 transmits and receives data between themobile device 260′ and the programmer 230. For example, the firsttransfer operation 1706 can transfer patient treatment historyinformation from the mobile device 260′ to the programmer 230. The datatransfer operation 1706 also can transmit a new treatment specificationor therapy schedule (discussed in greater detail above) from theprogrammer 230 to the mobile device 260′ for distribution to thepatient's controller 220 or regulator 210.

A voice transfer operation 1708 transmits voice data between the mobiledevice 260′ and the programmer 230. Typically, the voice transferoperation 1708 provides two-way voice transmission so the clinician canboth speak to and listen to the patient. The communication process 1700completes and ends at a stop module 1710. In alternative embodiments,the mobile device 260′ can transmit and receive other types ofcommunication to and from the programmer 230, such as text and/orgraphical data. For example, the mobile device 260′ can enable textmessaging between the clinician and the patient.

FIG. 18 is an example treatment system 1800 in which the controller 220and the DTD 260 have been combined into a single management device 1870having a memory 1872 and a transmission unit 1874. In general, themanagement device 1870 is configured to perform the same functions asthe controller 220 and the DTD 260 of treatment system 200. In anembodiment, the management device 1870 also can perform the samefunctions as mobile device 260′ discussed above. Treatment system 1800facilitates proper usage of the treatment system 1800 by the patient byreducing the number of devices with which the patient must be familiaror that can be lost, damaged, or destroyed.

Any of the above described methods and applications can be implementedusing the treatment system 1800. For example, the management device 1870can control the operation of the implanted regulator 210 by transmittingoperation instructions to the regulator 210 using any of thecommunication means described with respect to controller 220. Themanagement device 1870 also can store treatment events as a treatmenthistory in memory 1872. The management device 1870 can transfer thistreatment history to the programmer 230, the computing device 250, oranother remote device. The management device 1870 is configured tocommunicate with the other devices of treatment system 1800 over awireless communication link from a remote location using any of thecommunication means described with respect to DTD 260 or 260′.

The above specification, examples and data provide a completedescription of the manufacture and use of the invention. Since manyembodiments of the invention can be made without departing from thespirit and scope of the invention, the invention resides in the claimshereinafter appended.

We claim:
 1. A treatment system comprising: a regulator adapted to beimplanted within a patient, the regulator configured to apply atreatment to the patient, the regulator having a memory configured tostore treatment events; a computing device remote from the regulator,the computing device comprising a receiver module for receivingtreatment events from each patient; a storage module comprising at leastone database associated with each patient in which the regulator isimplanted for storing treatment events from each patient; and anevaluate module for evaluating patient databases stored on the computingdevice; a data transfer device comprising memory and a transmission unitconfigured to communicate with a controller and configured tocommunicate with the computing device over a network to transfer thetreatment events from the memory of the controller to the computingdevice for storage in the patient database and configured to transmitvoice and other data over a network between the patient and a healthcare provider; a controller configured to control operation of theregulator and adapted for placement on the patient, the controllercomprising a memory and a transmission unit, the memory of thecontroller being configured to store treatment events, the transmissionunit of the controller being configured to communicate with theregulator and with the data transfer device; wherein the data transferdevice communicates with the regulator through the controller; aprogrammer configured to be operated by a clinician at a location remotefrom the patient, wherein the programmer is configured to determinewhether the programmer has a current treatment history of the patient;and wherein the programmer is configured to communicatively couple tothe remote computing device to obtain the current treatment history ofthe patient if the programmer determines the programmer does not havethe current treatment history, and configured to generate and display atleast one report wherein the at least one report comprises a patient usereport indicating whether the patient operated the regulator correctlyover a period of time.
 2. The treatment system of claim 2, wherein thedata transfer device is a mobile device.
 3. The treatment system ofclaim 1, wherein the data transfer device comprises a start moduleconfigured to perform a connect operation between the data transferdevice and a device of the health care provider.
 4. The treatment systemof claim 3, wherein the device of the health care provider is theprogrammer, the computing device or a remote mobile device.
 5. Thetreatment system of claim 1, wherein the data transfer device comprisesa transmission module configured to transmit and receive data.
 6. Thetreatment system of claim 5, wherein the data is voice data, text data,or graphical data.
 7. The treatment system of claim 6, wherein the voicedata transmission is a two way voice transmission.
 8. A method oftransferring data between a patient and a health care providercomprising: using a system of claim 1 to: communicatively couple a datatransfer device of the system to the programmer, remote computing deviceor a remote mobile device; transmit the data to the programmer, remotecomputing device, or the remote mobile device; and receive and transmitcommunication between the programmer, remote computing device, or remotemobile device in response to the data transmitted.
 9. The method ofclaim 8, wherein the data transfer device is a mobile phone.
 10. Themethod of claim 8, wherein the data transfer device is communicativelycoupled to a remote mobile phone.
 11. The method of claim 8, wherein thedata transmitted is voice, text, or graphical data.
 12. The method ofclaim 11, where the voice data is a two way transmission.
 13. The methodof claim 8, wherein receiving and transmitting communication comprisesreceiving voice data at the data transfer device from a clinician, thevoice data including instructions from the clinician to the patient; andplaying the voice data at the data transfer device for the patient tohear.
 14. The method of claim 13, wherein receiving voice data at thedata transfer device comprises receiving voice data at a cellular phone,and wherein playing the voice data comprises rendering the voice dataand emitting the voice data from the cellular phone.
 15. The method ofclaim 8, wherein receiving and transmitting communication comprises:receiving at the data transfer device voice data from the patient, thevoice data including feedback pertaining to the effects of the treatmentregimen; and transmitting the voice data to the clinician.